home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Plus Special 23
/
AMIGAplus Sonderheft 23 (2000)(Falke)(DE)[!].iso
/
PublicDomain
/
Anwendungen
/
db3.6-beta-src
/
Readme
< prev
next >
Wrap
Text File
|
1999-11-14
|
3KB
|
81 lines
Source code for db3.4
Legal
-----
I've released the source code for db so you may add what you need.
However you are not allowed to use the source code for commercial
purposes, nor release modified versions under the name "db" without my
permission.
You can reach me at the following address if you have any questions:
david-ek@dsv.su.se
Regards
/David Ekholm
Building db from the code
-------------------------
The source code for db will compile under the SAS compiler (6.xx). Just
doubleclick on the build icon. Changes made to the SCOptions file will cause
a total rebuild of the project thanks to an intellegent makefile. This
makes it easy for you to make special versions for your particular processor
(020, 040, 060). However don't expect that much speed increase.
The main files
--------------
db is split upon many source files. Some of them are very specific, and some
are more general. Biggest of them all is db.c. It's a big and hairy one (the
first file). Others are very clean like the ARexx files. They can be used to
add ARexx ports to any program. Start your tour by reading db.h. There you will
find struct definitions that describe how db stores it's data internally.
The file dbparser.c handles parsing of the RFF format and building internal
structures that mirror this format.
dbGUI.c contains code that calculate the field positions and handle input
events which are in turn directed to db.c
Design.c contains code that allows the user to redesign a database view.
Select.c contains the code for the Browser window. It is made to work as
a general object for any purpose. You can easily create and use many select
objects at the same time.
The DesignGUI files are not used. They could have been the base for a
db with a better GUI design system.
Internal structure
------------------
I really should describe this more thorougly, but I don't have enough
inspiration so you will have to stick to this short text:
I wan't things to be as dynamic as possible in db in order not to run into
some annoying limitation. Therefore most data is stored in linked lists.
The main struct in db is the Pro struct. It stands for Project. Projects may
be stored in linked lists, thus enabling db to handle multiple databases at
once, but that possibility has never been exploited so only one Pro struct is
used. A global variable called CurrentPro points to this single project.
A project has it's own set of records stored in a doubly linked list.
Each record has a set of fields stored in one dynamically allocated chunk of
memory for speed and memory saving reasons.
A project also has a linked list of internal field information (FldInfo).
A project has a number of Layouts (that is the internal name for Views).
Each layout has a window with a number of visual fields (VisFldInfo).
Each visual field has a corresponding gadget which is displayed in the window.
Each visual field has a separator that controls how the next visual field is
drawn on the window in relation to itself. (A separator can be a space, tab,
newline or double newline.)
Each visual field also has a corresponding internal field in the database.
The projects, fields, layouts and visual field structs also has linked lists
of RFF tags that control different aspects of db.